2007-09

にっき

2007-08

開発日記

ぱどさんからの情報†

＞ところでAVR-USBのスループット向上ですがホストとデバイス間にHi-SpeedUSBハブを挿んでみてはいかがでしょう？

＞ホストからはHSのハブに転送させてハブにHSからLSにTTさせてみると速くなったりしませんでしょうか。

  • 確かに速くなりました。
  • コントロール転送が１５ｋＢ／秒になります。（ＳｉＳと比べて２倍、ｉｎｔｅｌ、ＶＩＡと比べて８倍速くなった）
  • ホストコントローラの種類に拠らず速くなります。
  • ＬｏｗＳｐｅｅｄバルク転送がうまくいきません。原因はまだわかりません。


  • ＨＳハブをＰＣ（ＥＨＣＩホスト）とＡＶＲの間に挟むことで、どうやらマイクロフレーム（125μＳ単位でのトランザクション：スプリットトランザクション？）が使用可能になるようです。

これは美味しいかも

↑

ＵＳＢハブ実験†

ＡＶＲ-ＣＤＣ改（最小限のＣＤＣでエコーバックのみを行うもの）を試してみた。

  • ＵＳＢ１.１ハブに繋いだ場合はＣＯＭ３：になり、teratermでエコーバック出来た。
  • ＵＳＢ２.０ハブに繋いだ場合はＣＯＭ５：になり、teratermで接続は出来るもののエコーバックが帰ってこない。
  • やはりＬｏｗＳｐｅｅｄバルクが殺されているような気がする。
    • ってやっぱりＳｎｏｏｐｙを動かして試さなきゃ！
↑

AVR_term†

ここまで作った。

bash ./checksize main.bin
ROM: 1696 bytes (data=6)
RAM: 95 bytes
  • コントロール転送のみを使う。
  • エンドポイントなし。
  • EEPROMのread/writeを削除したモニタをそのまま残す。
  • 最大４バイトの送信データを送信し、最大７バイトの受信データを受け取る。
  • ＰＣ側では簡単な送受テストを動作。


  • サイズ的には余裕のよっちゃん、なのでigorさんのと同じようにirdaとか追加できそう。
  • monitに仕込んでおいたポート内容のダンプ機能がデバッグに思いのほか役立った。
↑

ToDo†

  • 受信FIFOの正しい扱い 済み
  • 送信FIFOのFULLチェック 済み
  • 受信割り込みでの割り込み許可ポイント 今のところポーリングで受信しているので不要
  • ボーレート設定 済み
  • 送受テストばかりしてないでterminalとして動作させる 済み
  • 仮想com：のエコーバックを使用してcomポートに見せかける
↑

ＵＳＢｔｏシリアルが出来た。†

  • これでやっと、昔作ってずっと放置していたＡＫＩ-Ｚ８０やらＳｕｐｅｒ-ＡＫＩ をＵＳＢ接続出来るぞ、っと。
  • ジャンク箱をあさって、Ｚ８０なボードを掘り出した。

http:/ATMEL_AVR/upload/aki80.jpg

  • なんか、珍しい石英ガラス窓付きのチップが載っているぞ！
  • これが、おとぎ話に出てくる紫外線消去型ＥＰ-ＲＯＭってやつか？

どうする、おい

  • ＲＯＭライター持ってないぞ。

ここからさらに強引な展開

  • ＡＶＲでＲＯＭライターを作る。
    • いまさらＲＯＭライターかよ。
  • 多ピン品種のＡＶＲで２７Ｃ２５６っぽいＲＯＭの真似をする。
    • ATMEGA644-DIP40があれば可能だ。
    • しかし、本末転倒ではないか？
    • ATMEGA644-DIP40があればＺ８０なんかいらんだろ？

部品が乗る前の写真（秋月） http://img.akizukidenshi.com/images/org/k-123.jpg

  • もちろん、ＥＰＲＯＭは載っていない。あとで載せたものだ。
  • いまさらＺ８０アセンブラかよ。
    • （ＬＳＩ−Ｃってのも昔あったけれど、雑誌付録にいつも付いていてフリーなやつはＬＳＩ−Ｃ８６のほうだ）
  • これ１枚買うのも結構高かったよ（現在も入手できる。３０００円）
  • 今なら迷わずATMEGA644-DIP40を３個買う。
↑

仮想ＣＯＭエコーバックポートに対応中†

ここまで書いた。

  • CommEmuDrvをＤＬしてインストール。
  • ＣＯＭ５：とＣＯＭ９：を仮想ポートペア(エコーバック対)として作成。
  • AVRterm.exeを改造したcomm.exe で、ＣＯＭ９を開く。
  • ＣＯＭ９：から受け取ったデータはＡＶＲに流す。
  • ＡＶＲからの受信データをＣＯＭ９：に流す。
    こうすることで、ＣＯＭ５：に接続したteratermは、ＡＶＲのシリアルポートに繋がったことと等価になる（予定）
  • 一応書いてみた。
  • 一応動いたが・・・ごにょごにょ・・・反応が２Ｖ、じゃなかった鈍い。
  • キーをバタバタ打った後で１秒くらい置いて、ドカドカっと文字が帰ってくる。

なんで？

  • どうやらＡＶＲ側はシロだ。
  • ＡＶＲと交信せずに、ＷＩＮ３２内で完結するエコーバックを書いて回しても反応は同じ。
  • ところがWriteFile(Ex)せずに直接printfする場合はすんなりと速い。
  • COM9:に対するWriteFile(Ex)が発生すると長時間(0.5秒くらい)待たされているような感じだ。
  • これは同一ファイルハンドルCOM9を使ったReadFileExとWriteFileが競合するパターンのようだ。
  • 単体テストのときはうまく回避する術を見つけたような気がしたのだが・・・（気がしただけだったのか？）
↑

この、どうしようもない閉塞感は何なんだ・・・†

  • ＡＫＩ−Ｈ８/３０４８Ｆとそのライターボードをジャンク箱から発掘。
  • ＵＳＢにつなげてやろうと思った。
  • あれ？何これ？１２Ｖいるやん。
  • ２００ｍＡだと？大飯食いめ！
  • とりあえず通電してみた。動かない。なんで？ＦＬＡＳＨ消えたのか？
  • まあよい、開発環境は残っているかな？うーんＷｉｎ９５以前かな？だめだこりゃ。
  • ＲＳ２３２Ｃが２５ＰＩＮ　ＤーＳＵＢだ（ＰＣ９８仕様）

というか最密充填両面印刷で７００ページもあるＨＩＴＡＣＨＩのマニュアルは何なんだろう。

  • たしかに機能てんこ盛り。
  • いちいちアセンブラでコーディングしろと・・・。
  • 複雑すぎるんだよなー。このＨ８は。その割遅い。
  • 手間掛かりすぎるんだよなー。１２Ｖ要るし。
  • まあ、当時ワンチップで１２８ＫのＦＬＡＳＨが乗っているマイコンは他になかったような気がするが。
  • もう、いまさら使おうとは思わないんだよなー。
  • ＡＶＲに繋ぐのめんどくせーなー。やめよっかなー。

日の丸マイコンが凋落の日々となった理由の一端がすこしわかったような気がする。

  • だせーんだよ。何もかもが。

そう、いまさらＨ８を復活させて何か作ろうというわけではない。

  • 単に動態保存したいだけなんだ。
  • ビンテージパソコンコレクターと同じだな。
  • あと、コンパイラー揃えるの面倒だなー。ＡＶＲだけでいいやもう。
↑

仮想ＣＯＭエコーバックポートにて、手詰まり†

手詰まりとなった。

  • ＡＶＲとは接続しない状態で、ＣＯＭポートをオープンし、１バイトづつ文字を読み書きする。
  • すなわち、ごく単純な無手順ターミナルすら作れないという謎現象だ。
  • 突き詰めていったところ、WriteFile()でＣＯＭに書き込むと、それが反対側のＣＯＭポート（ｔｅｒａｔｅｒｍ）に表示されるまでに０.５秒くらいのラグが出来るのだ。
  • ReadFileもスレッドも一切使わない状態でもそうなる。
  • OVERLAPPEDをやめてもそうなる。
  • 送信文字数が１バイトだろうが１００バイトだろうが、０.５秒後にしか出現しない。
  • さらにたちがわるいのは、その期間内のReadFileが一切ブロックされることだ。

これがCommEmuDrv作成の仮想ＣＯＭにだけそうなるのか、リアルのＣＯＭでそうなるのかもまだ分からない。

  • ｔｅｒａｔｅｒｍ同士を仮想ＣＯＭで繋いで手打ちする限りはラグは起きない。
  • プログラムを使わずにコマンドライン上から 
    C:> copy file.txt COM5
    などとしても同様の現象に見舞われ、さらに悪いことにファイルの先頭しか送信されない。
    • ちなみに受信側はｔｅｒａｔｅｒｍ


激しく謎すぎてWIN32のCOMx:はようわからん・・・・。

↑

ComEmulDrvへの対応を断念した。†

症状：

  • ＣＯＭポートに送信(writeFile)して、０.５秒くらいのラグがあって文字が(teraterm側に)表示される問題。
  • 受信はまったく問題ない。
  • あと、問題は、空白の０.５秒の間にteratermで打った文字がぜんぜん受信できずに捨てられることだ。
  • まったく原因がつかめない。

じゃあteraterm同士では大丈夫なのか？

  • 試してみた。
  • ポートの方向によって、だめなときがある。
    • わりと、最後の１文字が０.５秒遅れで出たり、もう１文字書いたときに遅れて出たりする。
    • これはどちらかというとWindowsのカーネルのタイムスライスがおかしいんじゃぁ？
  • teratermでは文字が捨てられることはなさそう。
  • リアルＲＳ２３２Ｃポートではこのようになるというのは聞いたことない。
    • ComEmulDrvの癖なのかもしれない。
    • ソースを見たが、よく分からない。
    • Google先生にも聞いてみたが、使用例はごく少ないらしく、症例を発見できず。

Win32上でのComm関係でかれこれ３日くらい悩んだがもうあきらめよう。

↑

Ｈ８/３０４８Ｆ（季節柄秋なので、秋の月、秋月）のその後†

  • ２５ＰＩＮのパラレルコネクタは使わないっぽいので外して、そこにＵＳＢのＢコネクタ を実装してみた。
  • Ｈ８/３０４８Ｆ本体基板の３端子レギュレータを外して、ＵＳＢの＋５を直接Ｈ８の５Ｖに繋いだ。（本来はＨ８/３０４８Ｆ本体基板に１２Ｖが印加される仕様）
  • ＵＳＢ盗電システム成功。Ｈ８モニタ起動ＯＫ。
  • ついでに、ＡＴｔｉｎｙ２３１３を実装。
  • 部品は１００Ω×２、１.５ｋΩ×１、１２ＭＨｚＸｔａｌ、０.１μＦパスコン、ＡＶＲチップ、とたったこれだけで製作。
  • 何を省略したかというと減圧レギュレータ、Ｘｔａｌの負荷コンデンサ。
  • ＡＶＲは５Ｖ動作。
  • これで何の問題もなくＡＶＲ＿Ｍｏｎｉｔ入りのＡＶＲ＿ｔｅｒｍが起動した。

まだ、ＵＳＢシリアルからＨ８には繋いでいない。

  • というのは、Ｈ８/３０４８Ｆ本体基板のＲＳ２３２Ｃは、リアルＲＳ２３２ＣのＴｘＤ、ＲｘＤなので、レベル変換とインバータが必要だからだ。
  • Ｈ８/３０４８Ｆ本体基板上のＡＤＭ２３２を外して直結すればいいのだが、あんまり触りたくない。（配線が細いので・・・）
↑

さらにＡＫＩ８０接続した。†

  • 実はレベルコンバータが面倒だったので、いきなりＺ８０　ＳＩＯのほうに接続してみた。 
    #d 8000
8000 ff ff ff ff 0000 00 00 ff ff ff ff 0 00 00 00
8010 ff ff f df 00 00 00 0 ff ff ff fd 00 00 00 00
8020 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 00 00
8030 ff ff ff ff 00 00 00 0 ff ff ff ff 00 00 0000
8040 00 00 00 00 f ff ff ff 00 00 00 01 f ff ff ff
8050 00 0040 00 ff ff ff ff 00 0 00 00 ff ff f ff
8060 00 00 00 00 ff ff ffff 00 0 00 00 ff ff ff ff
800 00 00 00 00 ff ff ffff 00 00 00 00 ff ff f ff
8080 ff f ff ff 00 00 00 00 ff f ff ff00 00 00 00
80a0 ff f ff ff 00 0000 00 ff f ff ff 00 0 00 00
8b0 ff ff ff f 00 0000 00 ff ff ffff 00 00 0 00
80c0 0 00 00 0 ff ff ff ff 0000 0000 ff ff ff ff
80d0 00 0 00 00 ff f ff ff 0000 00 0 ff ff ff ff
0e0 00 0 00 00 ff f ff ff 0000 00 00 ff f ff ff
0f0 00 00 0000 ff ff f ff 00 00 00 0 ff f ff ff

惨敗。受信欠落多すぎ。

ＡＶＲの負け。

Ｚ８０の勝ち。

↑

直ったぜ！†

#d 8000
8000 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 00 00
8010 ff ff ff df 00 00 00 00 ff ff ff fd 00 00 00 00
8020 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 00 00
8030 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 00 00
8040 00 00 00 00 ff ff ff ff 00 00 00 01 ff ff ff ff
8050 00 00 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff
8060 00 00 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff
8070 00 00 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff
8080 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 00 00
8090 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 00 00
80a0 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 00 00
80b0 ff ff ff ff 00 00 00 00 ff ff ff ff 00 00 00 00
80c0 00 00 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff
80d0 00 00 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff
80e0 00 00 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff
80f0 00 00 00 00 ff ff ff ff 00 00 00 00 ff ff ff ff

ハイスピードハブを挟んだだけで直った。

  • ワンダフル！
  • ボーレートは３８４００bps
  • ＲＳ２３２Ｃ受信がポーリングによるものなので、直結だと開放タイミングがうまく確保できないのだろう。
  • 割り込み受信にするしかない？

モニタはこんな奴が入っていた。

↑

Ｈ８には勝った。†

  • 秋月Ｈ８/３０４８Ｆのマザーボード（兼ライターボード）に乗っていたＩＣ　ＮＥＣ２００３ の空きピンを利用してインバータ兼レベルコンバーターを実装。
  • ２００３はダーリントン接続の２Ｔｒが８個入っている。
  • まるでＬＥＤドライバーみたいなやつ。
  • これをＲＳ２３２ＣのＴｘＤにつないで、出力をプルアップしたのちＡＶＲのＲｘＤに繋ぐ。
  • 逆も同様。
  • どうやらＲＳ２３２Ｃから直結するとうまく行かない。
  • ＲＳ２３２Ｃラインがー１０Ｖに振れたときに逆流ダイオードに引っかかって死亡。
  • ３ｋオームを入れてとりあえずＯＫ。

結果

  • Ｈ８は１９２００ＢＰＳのモニターが起動する。
  • ＡＶＲも１９２００に合わせてＡＶＲ＿ｔｅｒｍを起動。
  • 今回はハイスピードハブがなくても受信文字欠落は無かった。

ＯＫ。出来上がり。

現在のステータス

  • ＡＶＲ＿ｔｅｒｍ経由でＡＫＩ-８０との接続に成功。（３８４００ＢＰＳ）
    • ただし、ハイスピードハブを挟まないと受信文字欠落が生じる。
  • ＡＶＲ＿ｔｅｒｍ経由でＨ８/３０４８Ｆとの接続に成功。（１９２００ＢＰＳ）
    • ＲＳ２３２ＣからＡＶＲへは余ったダーリントンでインバート接続した。
    • ハイスピードハブを挟まなくてもＯＫ。
↑

Ｈ８を勉強中†

Ｈ８のブートモードのおさらい。

ブートモード、ユーザープログラムモードともに、ＶＰＰに１２Ｖを印加。
ブートモードではさらにＭＤ２にも１２Ｖを印加。

  • ホストは00を何回か送る。
  • Ｈ８はそれを見てボーレートを調整する。
  • Ｈ８は調整できたら00をエコーバックする。
  • ホストは00を受け取ったら、次に55を送る。
  • Ｈ８は55に対してAAを返す。
  • ホストは、ＨＩ，ＬＯの順に転送プログラムサイズを送る。
  • ホストは、転送プログラム本体を送る。
  • Ｈ８は、それぞれをバイトごとにエコーバックする。
  • 転送が終わったら、Ｈ８はＦＬＡＳＨを全消去する。
  • 全消去が済んだらAAを返す。消去に失敗するとFFを返し、停止する。
  • Ｈ８は転送されたユーザープログラム(FF300もしくはFFF300からサイズ最大C00バイト)を実行する。
    • FFF300 はモード６のとき（１６ＭＢ）FF300はモード5,7のとき(１ＭＢ空間）

以上。

これらを実行してくれるツールがh8write.c なのだが、AVR_termに組み込むのは無理。

  • というのは、AVR_termには１バイト単位でのsend/recvをサポートしている論理層がないのだ。
  • 基本的にポーリングで（キー入力処理/ＡＶＲとの交信/文字表示）のループを回しているだけなのだ。
  • こいつをバイト志向のインターフェースにするには、ＡＶＲとの交信を別スレッドで回して、そのスレッドとメインスレッドのインターフェースをバイト志向のＦＩＦＯなりＰＩＰＥに改造しなければならない。（今はそうなっていない）
↑

PuTTYを試す。†

  • PuTTYはフリーなssh / telnetクライアント。
  • serialもサポートされている。
  • Windows / Linux と動作範囲は広い。
  • なぜだかわからないが PuTTYだと、ComEmulDrvとの相性が良い。
    不思議だ。
  • 不思議なことにOVERLAPPED引数エリアをReadFile() WriteFile() 直前に毎回ゼロクリアしている。
  • そんなことWIN32HELPに書いてないぞ。
  • やってみたが・・・今一つだ。
  • むしろ、readfileのthreadでsleep(1)しているのが悪いらしい。
↑

自分が馬鹿であることに気づいた（もっと早く気づけよ）†

  • Sleep(1mS)が悪い、と書いたが、実はそうではなくて。
  • ReadFile( ... OVERLAPPED &ovl );でIO_PENDINGじゃないときは、既に読み込み完になっている。
  • そのときはGetOverlappedResultとかWaitForなんとかとかは、一切不要で。
  • すでに受信できてるわけ。
  • なのに、そのデータを捨てちゃだめだよなー。＞アホ。

どうりで、teratermからのuploadをReadFileスレッドでぜんぜん受信できないわけだ。

  • Sleep(1)を外すと、「のほほん」タイムが省略されて、常にIO_PENDING状態になり、
  • たまたま受信できていたわけ。
↑

最近の思うところ†

OLIMEXのこれが欲しいんだな。

  • made in ブルガリーだが、どう考えてもＨ８の２０ＭＨｚに対してクロック比３倍、ＣＰＩ比４倍、 計１２倍は軽く速い
  • ＳＨ−２と比べてもこっちのほうが良さげ。消費電力でもＳＨより少ない。
  • フラッシュ５１２Ｋ、ＲＡＭ４２ＫＢと、十分な容量。
  • おまけにＵＳＢ　ＦｕｌｌＳｐｅｅｄ内蔵だな。
  • ＡＲＭなのでコンパイラには不自由しないし、アセンブラで書いても速い。

こうなってくると、もうるねさすなんかいらないという感じ。

  • というか秋月さん、Ｈ８はもういいからこんなナイスなボード売って。（OLIMEXのデッドコピーじゃないやつね）
    • 意訳：ＣＰＩの悪いコストパフォーマンスの悪いＨ８はもう保守品種にしてしまっていい。
    • ＵＳＢとかＬＡＮは欲しい。あとは適度にクールなＣＰＵを安く載せて。
    • ＥｚＵＳＢ　ＦＸ２はいくらＨｉＳｐｅｅｄでも（８０５１だから）嫌だ。


じゃあ何かい？。今までのＡＶＲとＨ８は回り道だったってこと？

↑

ＭＩＰＳも面白いかも。†

こっちはOLIMEXじゃないけれど、１００ＢａｓｅＴが４ポートとシリアルとＵＳＢが付いて３８００円だ。

ＭＩＰＳの１７５ＭＨｚ、８Ｍ　ＲＡＭ　２Ｍ　ＦＬＡＳＨだ。ＯＬＩＭＥＸを超えている。

しかも、Ｂｕｆｆａｌｏだぜ。普通のパソコンショップに売ってるし。

改造するなら、ジャンクで入手すべきだが。

  • ひとつ注意しておくと、ＵＳＢはデバイスではなくてホストだ。
  • だが、Ｌｉｎｕｘ化出来るので、各種ドライバーは揃うわけで、楽だろ。

下手に実用品として使おうとしないこと（たとえばＷｅｂサーバーとかＦＴＰサーバーとかインターネットに晒すとか）

  • 実用品なら玄箱買っとけ。あっちはＲＡＭがこの１６倍はある。
  • 実用品じゃなくて、マイコンボードと考えると、なんなんだろうこの高機能っぷりは！１７５Ｍｈｚのボードなんて１万円でも買えないぜ。しかもＬｉｎｕｘ動いてるし。
  • EtherNetのハブ(もしくはルーター)＋αとして実用に使うは善し。＋αの部分はあまり多くを望まないこと。
↑

Win32 Commポートリベンジ！†

  • なんかほんとにteraterm-->ComEmulDrv-->自作Comm通信は相性が悪いようだ。
  • 症状としては、Commに対するReadFileとWriteFileの発行（オーバーラップも含め）が重なるだけでダメダメになる。
  • teratermの代わりにPuTTYだと、割といい感じ。
  • なぜだかわからない。
  • 文字欠けの問題は、Commに対するReadFileとWriteFileの発行（オーバーラップも含め）が重ならないようにセマフォとかMutexで制御することで回避は出来るが、送信が起きると受信文字が妙に遅れてくる問題はそのままのようだ。
  • ちなみにWriteFileせずにconsole printするような（半二重通信）アプリにすると、どちらのtermでも快調だ。

Win32のCommはほんとにようわからん。

↑

結局のところ、半二重でよいからとっととやっつけてしまおう的なソリューションを取ることにした。†

要はh8write.cが動けば（AVR tiny2313経由でH8/3048Fに書ければ）いいというそれだけなのだ。

  • だから、文字欠けさえなければ、応答が遅かろうがどうでもよい。
  • h8write.cのやりかたが、けっこう投槍的なので、真似しようかと。（ERROR_IO_PENDINGなんか見てないし）

結果、成功。

  • わざわざWIN32用の無手順端末を書いた。
  • 投槍的にはせずに、普通に書いてみた。
  • RS232C受信文字があるかどうかをポーリングする関数ClearCommError()を使って、結局スレッドは用いなかった。
  • さらに、無手順端末モードの他にエコーバックサーバーモードを追加した。
  • ２つのtermを立ち上げ、片方をエコーバックサーバーにして、もう片方を無手順端末にする。

ばっちりだ。

  • 無手順端末でなくteratermを使ったときだけ、応答が遅い現象が起きる。
  • PuTTYでは起きないので、teratermだけ本物のRS232Cポートを仮定した何かのエラーチェックがあるのではないか？？？
  • ComEmulDrvのCOMポートに対して、GetCommProperties()を発行すると、COMPROP構造体がオールゼロのままで何も情報を返さないので、やはり実在COMポートとは異なるようだ。